Use current time as start time for OMTG #6353
Conversation
| @@ -204,7 +204,7 @@ public class OpenModelThreadGroup : | |||
| val seed = randomSeed | |||
| val rnd = if (seed == 0L) Random() else Random(seed) | |||
| val gen = ThreadScheduleProcessGenerator(rnd, parsedSchedule) | |||
| val testStartTime = JMeterContextService.getTestStartTime() | |||
| val testStartTime = System.currentTimeMillis() | |||
There was a problem hiding this comment.
Do we have something like "setup completed timestamp" or "main test started (excluding setup)"?
There was a problem hiding this comment.
I am not aware of such a thing.
But do you think this is needed? ThreadGroup#start gets called, when the thread group should start, so this seems to be enough (for now?).
There was a problem hiding this comment.
JMeterContextService.getTestStartTime is used in ConstantThroughputTimer, PreciseThroughputTimer.
I expect the classes will have the same issue regarding long setup thread groups.
At the same time, all of those might appear under setup thread groups as well. WDYT of using something like "thread group start time"?
Of course, for OMTG it is a bit easier as start corresponds to the thread group start, however, the timers should probably refer to the start time of the corresponding thread groups.
There was a problem hiding this comment.
Right, if they use the same timestamp to calculate the beginning of the thread group, they are misled, too.
Do the timers have access to their respective thread groups?
There was a problem hiding this comment.
There's JMeterContextService.getContext().getThreadGroup().
However, AbstractThreadGroup does not track its start time :-/
There was a problem hiding this comment.
We could add a setStartTime/getStartTime pair on the AbstractThreadGroup and set the start time before JMeter calls ThreadGroup#start.
There was a problem hiding this comment.
It sounds like a good plan.
ConstantThroughputTimer has "shared" mode which means it somehow operates across the thread groups, so I am not sure which "start" timestamp it should use then.
There was a problem hiding this comment.
Yes, there has to be done more logic in the ConstantThrouputTimer. The delay has to be calculated depending on the mode. So I left it out now, but it could be added later.
src/core/src/main/java/org/apache/jmeter/threads/AbstractThreadGroup.java
Outdated
Show resolved
Hide resolved
When we use the test start time via JMeterContextService#getTestStartTime, we might create a storm of test samples at the beginning, when a setup thread group made us wait.
…roughputTimer A thread group might start later than the test. When we calculate delays on the start time of the test, we might get a stampede of samples run at the start of the thread group.
FSchumacher
force-pushed
the
start-time-for-omtg
branch
from
06074bc
to
7848ff4
Compare
Description
Use current time as of actually starting the open model thread group
Motivation and Context
When we use the test start time via JMeterContextService#getTestStartTime, we might create a storm of test samples at the beginning, when a setup thread group made us wait.
Related to #6352
How Has This Been Tested?
Used the test plan attached and looked at the req/s values. They should be in the range of 1 req/s.
omtg-and-setup-group.jmx.zip
Screenshots (if appropriate):
Types of changes
Checklist: